SMART on FHIR with Okta - Implementation Template

• SMART on FHIR Discovery
• Dynamic Registration
• Manual Registration
• Standalone Launch Sequence
• OpenID Connect
• Token Refresh

Inferno is an open-source tool that tests whether patients can access their health data. It makes HTTP(S) requests to test your server's conformance to authentication, authorization, and FHIR content standards and then reports the results back to you.

You can use the SMART Application Launch Framework Implementation to test the Mule application on Inferno FHIR Testing.

SMART on FHIR Discovery

The FHIR Server:

• Makes a SMART configuration available from the Mule application’s well known endpoint.
• Validates for required fields.
• Matches the endpoints from the conformance statement (response from smart-configuration endpoint) with metadata endpoint.

You should see the following response when you execute the Run on UI:

Dynamic Registration

You can verify whether the server supports OAuth 2.0 Dynamic Registration protocol. Executing the following test creates an application in Okta.

Click the Run button in the UI and then update the following parameters:

1. Add ‘fhirUser’ in scopes.
2. Enter unique oAuth Client Name.
3. Select the Dynamic Registration Endpoint (this is the mule application /clients endpoint).
4. Select Confidential client.

Note: OAuth Client Name (Application name in Okta) is unique.

Execute the test and verify that the client is created in Okta under the Applications Tab > Applications Section:

Manual Registration

To manually register the Inferno application with the authorization service, click the Run button in the UI and then execute the test.

Additional Steps

Before Running the next test "Standalone Launch Sequence", grant access to the new client ‘Inferno’ that is created in the Dynamic Client registration test:

Standalone Launch Sequence

The Standalone Launch Sequence allows an app, such as Inferno, to be launched independently of an existing EHR session. It is one of the two launch methods described in the SMART App Launch Framework alongside EHR Launch. The app will request authorization for the provided scope from the authorization endpoint, ultimately receiving an authorization token which can be used to gain access to resources on the FHIR server.

Inferno will redirect the user to the authorization endpoint so that they may provide any required credentials and authorize the application. Upon successful authorization, Inferno will exchange the authorization code provided for an access token.

To execute, click the Run button in the UI and then execute the test. All the steps in the execution should be successful:

EHR Launch Sequence

The EHR Launch is one of two ways in which an app can be launched, the other being a Standalone launch. In an EHR launch, the app is launched from an existing EHR session or portal by a redirect to the registered launch URL. The EHR provides the app with the following two parameters:

• iss - contains the FHIR server URL.
• launch - an identifier needed for authorization.

All the required fields will be pre-populated. Select confidential client, validate scopes, and then execute the test:

A pop-up window with Launch URI opens in the UI.

Generate the Launch URI by adding the following URI parameters and then execute in the new browser window:

• Base URL – URL that is provided in the Launch URI window.
• launch – Provide a random alphanumeric value.
• Iss – Mule Application URL.

Example

https://inferno.healthit.gov/community/oauth2/static/launch?launch=12345=<MULE APP_URL_DEPLOYED>

OpenID Connect

OpenID Connect (OIDC) provides the ability to verify the identity of the authorizing user within the SMART App Launch Framework. Applications can request an id_token by including the openid fhirUser scopes when requesting authorization.

To execute, click the Run button in the UI and then execute the test. All the steps in the execution should be successful:

Token Refresh

The Token Refresh Sequence tests the ability of the system to successfully exchange a refresh token for an access token. Refresh tokens are typically valid longer than access tokens and allow client applications to obtain a new access token. Refresh tokens themselves cannot provide access to resources on the server.

To execute, click the Run button in the UI and then execute the test. All the steps in the execution should be successful: